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ABSTRACT 

The Personal Database Management System is a hardware 
and software system designed to support people's memory and 
recall processes. It is a small, low power, and inexpensive 
microcomputer system which employs E 2 PR0M and CMOS tech- 
nology. The design is based upon how people manage their 
personal information, which was found to be different from 
the ways conventional computerized systems manage 
information. 
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I. INTRODUCTION 



One of the factors which limits human performance is the 
limited capacity of human memory. Memory is commonly 
considered to be divided into two parts: short-term and 

long-term. Short-term memory is that part which we can 
consciously access; it may be compared to the primary store 
of a computer. It is characterized by rapid access and 
volatility. Long-term memory is analogous to secondary 
storage in that it is more permanent in nature than short- 
term memory and it requires more time and effort to record 
information to and retrieve information from [1]. 

Short-term memory is a major limiting factor on human 
performance because it is the memory which is consciously 
accessible and thus our working memory, and it is very 
limited in its capacity. This memory holds units of infor- 
mation for up to thirty seconds. That period may be 
extended through repetition and rehearsal. The size of 
short-term memory is approximately seven units of informa- 
tion (plus or minus two) . The nature of these units is a 
function of experience and training. For example, someone 
familiar with English may find it easy to remember seven 
English words but difficult to remember seven Chinese ideo- 
grams. Thus it is easy to see that the information 
processing capacity of humans can be easily overloaded. 
Long term memory limits performance because of the time and 
effort associated with fetches from and stores to it [1]. 

The idea behind a Personal Database Management System 
(PDBMS) is to provide an extension to both short-term memory 
and long-term memory. A good PDBMS should provide its users 
with means of storing information and later retrieving it 
that are faster and more efficient than ordinary human 
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means- Long-term memory can be extended by allowing users 
to easily store information which they find difficult to 
memorize. Numerical information such as phone numbers, safe 
combinations, and part numbers are examples of information 
which are usually expensive in the amount of effort required 
to ensure that they are not soon forgotten- Short-term 
memory can be extended by providing users with a way to 
relieve the burden upon its capacity. Instead of having to 
remember a piece of information or a key (or cue) to 
retrieving the desired information, a PDBMS can accept the 
key as input and retrieve the desired information. Once the 
key has been entered into the system, it may be forgotten, 
freeing a portion of short-term memory for more information. 
Also, retrieved information need not be memorized if the 
PDBMS records it in a manner which allows it to be easily 
accessed. For example, information recorded on a piece of 
paper or on a display screen need not be memorized if it is 
within easy reach. 

What should be the characteristics and what are the 
requirements of a Personal Database Management System? 
Because it is designed for the storage and retrieval of 

per so nal information, it is a single-user system. In order 

to be useful to a broad range of people, it should permit 

interaction at different levels, depending on the sophisti- 

cation of the user. Novice users will be easily discouraged 
and see very little benefit if a system appears to be illog- 
ical and complicated. Also, because of the personal nature 
of the information in the database, the system should 
provide security to that information. Finally, in order to 
be acceptable, it should be small, light-weight, and 
inexpensive. 

This last requirement was taken to indicate that such a 
system should be built using a battery-driven micropro- 
cessor. Current microprocessor technology provides more 
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computer power than is needed strictly for a PDBMS. So the 
design presented here incorporates the following additional 
capabilities: 1) the ability to be used as a calculator, 2) 

the ability to be programmed by the user, and 3) the ability 
to be connected into networks or to other devices via an 
RS232 serial interface. 

The PDBMS is programmed in a non-standard version of 
FORTH. The particular one used here is neither fig-FORTH 
nor FORTH-79, the two most prevalent versions of FORTH. 
However, the basis for the language used is 8080 fig-FORTH, 
version 1.3, which was partially modified to conform with 
the FORTH-79 standards [2]. Further modifications were made 
to this based upon hardware characteristics, and the sugges- 
tions and ideas of various members of FORTH Interest Group. 
In spite of this, when referred to in this thesis, the 
language used in the PDBMS will be called FORTH. One major 
distinction should be made, however, the PDBMS's base vocab- 
ulary is called ROOT, not FORTH. 



13 



II. PERSONAL DATABASE CHAR A CTEBISTIC S 



A. BACKGROUND 

The largest part of the information presented in this 
chapter was derived from detailed study of four personal 
address books (Appendix 3 contains detailed statistics from 
this study). Address books were used as a basis for the 
preliminary investigation of personal databases because they 
were found to be more structured, standardized, and easily 
computerized than other personal databases (e.g., shopping 
lists, appointment calendars, and things-to-do lists). 

The people (some of whom worked with computers daily) 
interviewed during the study indicated that the maintenance 
of personal databases is not analogous to management of 
databases by computer. Indeed, the ways in which a database 
management system (DBMS) is structured, maintained, and used 
is very different from the way people manage their personal 
information. The results of the author's studies and inter- 
views seem to indicate that the essential difference between 
DBMSs and personal information management is the number of 
"system" users. It is this difference that is the apparent 
cause of most all of the other differences. 

Because DBMSs are normally organizational tools with 
many users, records, fields, attribute values, query 
languages, keys, etc., they must be standardized. Because 
organizational data is entered and retrieved by many 
different individuals and thus without standardization, it 
would be difficult for one person to know of information 
entered into the system by another, much less retrieve it. 
On the other hand, personal information is shared by only a 
few people, if any. An important point here is that in such 
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a situation where there is only one user, that user knows 
(or knew at one time) all of the information in the system 
because he entered it. People record and maintain personal 
information in an auxiliary store in order to relieve them- 
selves of some of the burdens of recall and recognition. 
Because long-term memory is generally considered to be 
permanent [1], the data recorded in auxiliary stores need 
not be a verbatim copy of the information which is to be 
retrieved later. Truly personal information needs only to 
contain enough context-specific cues to enable a person to 
reconstruct or recall the structure of their semantic 
memory. 

"The Recognition of Previous Encounters," by George 
Handler [3] describes semantic structures as an organization 
of memory (referred to as a "familiarity variable") . These 
structures represent the familiarity of events (and of the 
entities which are part of an event) , and are unique to each 
particular event. Further, they are independent of the 
context in which the event occurs or in which it is 
embedded. Two sets of independent processes operate upon 
semantic structures: intra-event processes which are 

referred to as "integration," and inter-event processes 
which relate an event to others called "elaboration." 
Handler's hypothesis is that recognition is related to inte- 
gration, which is developed through attentive repetition 
(rote learning) . Recall is related to elaboration, which is 
strengthened by the establishment of relational links 

between the target event and other representations in 
memory 1 . Mandler does not describe how integration and 



Recognition is the process of going from a familiar 
event to the context which caused the event to be remem- 
bered. Recall is the opposite process, that is, remembering 
an event from its context. When a person attempts to 
remember where he knows a familiar face from, he is 
employing recognition. Recall is what a person attempts to 
do when ne knows his wife told him to get something on the 
way home, but has forgotten what. 
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elaboration manifest themselves except in an abstract way. 
They must involve the establishment of cues which act as 
keys to semantic structures whether they might be direct (as 
one would expect in the case of integration) or indirect (as 
might be the case for elaboration) access. It is these cues 
which must be available to a person in order to retrieve the 
desired events and entities. It is this that makes personal 
databases different from DBMSs. 

Even though only the minimum number of cues need be 
saved in order to retrieve information, the author's studies 
revealed that usually more than the minimum required cues 
are recorded. For example, there is usually no need to 
record one's parents' city and state of residence, yet every 
address book contained this, as well as other unnecessary 
information. This is probably due in part to the fact that 
address books are not always personal databases, sometimes 
they are family documents. Appointment calendars appeared 
to be the tersest of all the personal databases studied. An 
example entry for March 10 might be, "Rebecca 11:30" which 
is a reminder that Rebecca has an appointment with Dr. 
Feeney at the Pediatric Group, 698 Cass Street, 11:30 A.M., 
on March 10th. 

In order to establish a common ground for comparison, 
the following terms will be used throughout this thesis. 

• Personal Database Mana g emen t System (PDBM S) : a computer 

Base'S system “for managing “personal information. The 
information managed bv this system is organized into 
files containing records. 



• Manual Database (MDB),: a manually maintained file of 

personal"* information. 3ecausa these databases are 
normally not systematically managed as a group, there is 
no MDBMS analogous to a PDBMS. Each MDB is seDarate and 
distinct from all other MDBS ; an address book; appoint- 
ment book, etc., are each MDBs. 



• File: a relationship between records. An MDB is a 

file. All records in a file are of the same format and 
related by the their grouping into the same file. 
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• Record: an entry in a file. In an, address book each 

nine a person or an organization is added to the 
"address book file," a new record is added. 



• Field: an entry in a record. In general, all records 

In tie same file have the same fields (and thus struc- 
ture). In an address book, the fields are usually 
called "name," "street." "city, state, and zip code," 
and "telephone number." 

B. GENERAL CHARACTER IS! ICS 

As stated before, people do not generally view personal 
data as a database in the same sense as information in a 
computerized database. Each MD3 tends to be viewed as a 
distinct entity, unrelated to any other MDB. Thus there is 
no notion of a database management system {DBMS) since the 
MDBs are not managed together as a group. As a result there 
is often redundant information in MDBs when they are viewed 
as a group. For example an address book and an appointment 
calendar probably both contain redundant information about 
an individual's insurance agent, realtor, dentist, etc. 
Even though the possibility for joins and Cartesian products 
exists, they are not only not performed, but the concepts 
behind these operations are apparently incomprehensible to 
the layman. 

The existence of separate MDB's or files can be intui- 
tively explained by three reasons. First, and most 

obviously, is that the amount of effort required to maintain 

even a partially integrated database manually costs more 

than the value gained by having such a database. 

Maintaining such a database requires the establishment of 
all possible desired relationships before the implementation 
of the database followed by the maintenance of complicated 
and troublesome cross-indexes. Less effort is required to 
check one's appointment book for appointments and then go to 
one's address book to obtain the phone number to call in 
order to confirm an appointment; or if the requirement for a 
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confirmation was foreseen, to simply duplicate the phone 
number in the appointment book. 

The second reason is more subtle and might be related to 
the ideas expressed in reference [3]. Even though the same 
entity (person, organization, etc.) may be included in more 
than one file, the different occurrences may represent 
different views of that same entity; that is, file entries 
are context-sensitive. When comparing address book records 
to appointment calendar records, it is very common to find 
that the address book entry for an individual is more formal 
than an appointment book entry for the same individual. For 
example "Richard Elton" might appear as "Richard and flay 
Elton" in an address book, "Rich" in an appointment book, 
and "Lt. Elton" in a personal note. This context-sensitive 
nature of entries seems to indicate that integrating a 
personal database is much more difficult than in the case of 
traditional DBMSs. 

The last reason is that inconsistencies between personal 
MDBS (i. e. , files) due to replication (redundancy) of data 

is easily managed. This is not only because of the indi- 
vidual and aggregate file sizes, but also because of the 
nature of the data. The issue of size is obvious; the 
important characteristic of the data which aids in solving 
the problems of inconsist ency is that the keys used for 
access are closely related, if not identical, to cues used 
to reconstruct semantic structures. For example, when a 
person receives a change to his friend Pat's phone number, 
it will probably prompt him to make a change in his 

address/phone book. What changed was not the entity "Pat" 
but just a value of one of the entity's attributes. So for 

the most part, the cues (which are context-free) associated 

with "Pat" remain unchanged. There is a good possibility 
that ail occurrences of the old phone number will not be 
updated. Later when he comes across an occurrence of the 
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old number, it will elicit many of the same cues related to 
•'Pat" as would the address book entry. Chances are that he 
will remember that the number was changed and was recorded 
in his address/phone book. It will be then that the incon- 
sistency will be corrected, if it is at all. Perhaps people 
rely upon this and intentionally do not make any great 
effort to seek out inconsis tencies. 

1 . Piles 

Manually maintained files are apparently organized 
in two ways: sequential access and direct-keyed access. 

MDBS which are direct-key accessed are normally recorded in 
a commercially procured file or document. Examples of these 
files are address books which are designed to be keyed on 
the first letter of a surname in the ’’name" field or 
appointment books which are designed to be keyed on a date. 
Sequentially maintained files are commonly kept on less 
rigidly structured media such as notepads, chalk boards, or 
scraps of paper. Information is usually entered chronologi- 
cally. Shopping lists, things-to-do lists, etc., are 
examples of sequentially organized files. • Another distinc- 
tion between the two file types is the time-value of the 
information stored in them. Indexed files usually contain 
information which is to be retained for a longer period of 
time than that contained in sequential files. It was not 
uncommon to find address book entries which were more than 
ten years old. 

2 . Re cords 

With the exception of personal notes, records within 
any particular file tended to be fairly uniformly formatted. 
There is generally a core of fields which contain a value in 
almost all records. However many records contained addi- 
tional fields beyond the "core-fields. " In the case of 
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address books these fields were inserted into the pre- 
printed record formats by writing them vertically, placing 
them in an unused, unrelated field, or placing them into 
another record. The "core-fields" in address books are: 
"name," "street," "city," "state," "zip code," "area code," 
and "telephone exchange and number." Typical additional 
fields contain information such as: 

• Account, Model, Serial, Policy, and Social Security 
Numbers. 



• Additional Phone Numbers (e.g., "home," "work," 
"marketing department," "service," "account inquiries," 
etc. ) . 



• Birthdays and Anniversaries. 

• Additional Names (e.g., children's names, points of 
contact) . 



• Cards and Favors Sent and Received. 



* Additional Miscellaneous Information (e.g., "When in 
Seattle," "Neighbors in Monterey," or "Uncle Bob's 
brother-in-law" ) . 

In the case of address books, record deletion 
appears to be an unpredictable event and probably a function 
of the medium upon which it is recorded. Bound address 
books contain many more entries whose validity are question- 
able. Many of these appear to be retained not only because 
they were entered in ink, thereby making deletion a messy 
affair, but for sentimental reasons. Many of the very old 
entries are for high school and childhood friends. Address 
books which permit easy deletion of records appear to 
contain fewer old entries, but because deletions are not 
recorded it is not easy to attribute this effect to the ease 
of deletions. 
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3 . Fields 

Even though the fields' types and numbers appear to 
be fairly standardized, the contents of the fields is not. 
Fields appear to be variable length with no restriction on 
content. Graphic, non- alp ha numeric symbols such as hearts, 
check-marks, and "happy faces" are not uncommon. Some files 
contain indicators of the validity of the information in the 
field (e.g., "?" or "as of Dec 81"). Abbreviations are not 
consistently used in the same file; for example, one address 
book examined contained all of the following entries; 



Street 


St. 


Str . 


Avenue 


Ave . 




Virginia 


Vir g. 


7a VA 


Mr. & Mrs. 


Mr/ Mrs 


Mr. and Mrs. 


DESIGN IMPLICATIONS 


It appears obvious 


that a PDBMS 


and a DBMS are not 



same. As such, it is reasonable to construct a PDBMS 
differently from a DB US. Because a PDBMS is used as an aid 
to recall contexts from memory, and the cues to these are 
unique to each context [3], not only should the system have 
no restrictions such as fixed field lengths and attribute 
values, but additionally it should; 



• Allow the user to use any word as a key. 



• Be able to recognize and compensate for misspelled keys. 



• Be able to take into account keys which are synonyms and 
refer to the same entity (for examples see the descrip- 
tion of fields, above) . Also it should have the ability 
to discriminate between homonyms which appear to be the 
same but refer to different attributes or entities (for 
example, "CT," as an abbreviation for "Court" in a 
street address versus "CT," as an abbreviation for 
"Connecticut") . 
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When interviewing laymen, it was found that they easily 
understand the concepts of "file" and "record," but not 
"field." This suggests that perhaps people conceptualize an 
entity as a synergistic sum of its attributes rather than as 
a relationship between attributes. Thus a record is the 
smallest logical unit with which people normally deal 
because it, as a whole, contains the cues necessary to 
reconstruct semantic structures. The number of fields in a 
record may be related to an individual's ability to "inte- 
grate" the corresponding semantic structure [3]. 

Because a PD3MS is an aid to an individual's recall, it 
should faithfully preserve information entered and retrieve 
it by logical means. If text compression or compaction 2 is 
employed it must be transparent to the user. logical 

retrieval means that if the user feels that he has given 

sufficient information to specify the desired data, the 
system should be able to either retrieve the data or give a 
comprehensible reason why it could not be retrieved. 

a PDBMS should be "user friendly" and require very 
little effort on the part of the user. This means that 
persons who have no need or desire to understand computers, 
DBflSs , etc., should be able to use the system. Further, 
file, record, and field formats should be easily specified 
without the need for a plethora of technical details. Entry 

and retrieval of data should also be fast and easy. Host 

people who are not specifically trained on computers tend to 
have much less tolerance for poorly engineered computer 
systems or ones requiring a technical expertise than do the 



2 Text compression and compaction involve removing redun- 
dant information from text so that it can be stored using 
fewer resources than if the original text had been stored. 
The difference between the two is that an exact coDy of the 
original text is recoverable after compression, whereas it 
is not from compaction. 
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system's designers cr computer sciantis 
computerized sysrem must be better in 
corresponding manual system [1]. 



s [ 4 ]. Above all, a 
every vay than the 
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III. HIGH LEVEL £ DBMS SYSTEM DESCRIPT ION 



A. SOFTWARE 

When the user first receives the PDBMS , he sees only two 
functions: a calculator and a database management system. 

As the user learns how the system works, it is possible for 
him to expand the system incrementally until eventually he 
can reprogram a large portion of the system itself in FORTH 
and/or assembly language. 

Many of the keys on the PDBMS* s keyboard are program- 
mable. They are initially used to allow the user to enter 
commands by simply pushing a key. Instead of typing 
'•RECORD'* when using the database management function, the 
user needs only to push the " SHIFT 1 ’ and "R 11 keys and the 
system will enter the word "RECORD” for him. 

1 • The Calculato r Func tion 

The calculator which the user initially receives is 
much like any other calculator. Two major ways in which 
this function differs from most standard calculators is that 
a series of arithmetic operations may be entered at once, 
and that the user may create and use variables. Unlike most 
calculators, the action of most of the keys on the PDBMS is 
simply to enter textual data into the system. The PDBMS 
does not interpret most of the input until the ENTER key is 
pressed. So the following two key sequences have the same 
effect, i.e., to add two to three and obtain five. 
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2 

<space> 



2 

<enter> 

+ 

<enter> 

3 

<enter> 

<enter> 



+ 

<space> 



3 

<space> 
<en ter> 



Like in FORTRAN, variables are created when they are 
first used. If a word or a character is found in the input 
which t he calculator cannot recognize and it is to the right 
of an egual sign, it assumes that it is a variable declara- 
tion and creates one. If an unrecognizable word or 
character is encountered to the left of an egual sign, an 
error condition is signalled. 

2. The Database Man age ment Function 

The database management function allows the user to 
create files and records, delete files and records, retrieve 
records, and use keys (i.e. , passwords) to seal records and 
other keys as a means of providing data security. The user 
is not required to deal directly with the technicalities of 
database data structures, he only needs to know that files 
are a collection of records, all having the same format. 
Files appear to the user to be separate and disjointed, 
similar to MDBS. The procedure for creating a file requires 
only that the user specify the file's name and the names of 
the fields within the records of the file. The user is led 
through the process of file creation and record retrieval by 
system prompts. 

Records may be retrieved by using any word (or group 
of words) contained within them. The only restriction on 
this is that the user must specify which field is to be 
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searched for the target word(s). This restriction should 
not seem unnatural to the user but, rather, necessary. 
Because any word is a possible key attribute, the user must 
be able to specify the context of the target word. By spec- 
ifying the field name with queries, the user is able to 
retrieve a record using Mr. York’s last name without also 
retrieving all of the records containing "New York." 

B. DATA STRUCTURES 

The PDBMS uses some data structures which might be 
considered unusual when compared to other database applica- 
tions. Some of these are characteristic of FORTH and others 
are used because of the nature of the system. 

1 • Dictionar ies 

Two different dictionary structures are used in the 
PDBHS. One dictionary is that which is associated with 
FORTH. The second is conceptually more like a dictionary, 
as a layman might think. A FORTH dictionary is simply a 
linked list of FORTH definitions. The definitions are main- 
tained in chronological order by their time of creation. 
These definitions typically describe the following basic 
FORTH word-types: colon definitions, constants, variables, 

user variables, and vocabularies. Colon definitions are 
FORTH definitions which are defined in terms of previously 
created definitions, similar to procedures and functions in 
other languages. Vocabularies are "sub-dictionaries" and 
are used to delimit the scope of definitions. 

The other dictionary is called the DB dictionary and 
it is used to store the words entered and contained in the 
database. Words are entered into the dictionary and 

looked-up by hashing to a linked list using the first letter 
or digit of the target word, and then traversing the list. 
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which is alphabetically sequenced. Punctuation is not 
stored in the D3 dictionary. 

2. Files 

Files are completely inverted. They contain only 
administrative data, and indices and pointers into the D3 
dictionary. Information which is retrieved from the data- 
base is reconstructed a word at a time by looking words up 
in the dictionary (punctuation is stored directly in the 
database in its ASCII format). Memory for files, the DB 
dictionary, and sealed keys (discussed later) are allocated 
from a heap so that none of these data structures occupy 
contiguous memory. A file is defined as a FORTH vocabulary 
and its definition contains pointers to the first and last 
records in the file. Records are maintained as a circular, 
doubly linked list. The fields are defined as FORTH 
constants in their respective file’s vocabulary. Their 
value is an ID number which is used to relate the fields in 
the database zo the names assigned to them by the user. 

3 . Lo gical R ecords 

To the user a record appears to be a collection of 
information related to a particular entity. The fields help 
to organize the data by grouping it. The logical record 
itself is variable in length. The first set of bytes in a 
record contain the record's access descriptor, which is 
variable in length. This is followed by the links (or 
pointers) to the previous and next records in the file. 
Following these pointers are the fields which are fixed in 
number (as determined in the file's definition), but are 
each variable in length. Fields are separated by an 

end-of-field (EOF) marker. Because records contain a fixed 

number of fields, the last EOF serves as a end-of-recora 
mar ker. 
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4. 



Fields 

Fields are a continuous string of bytes which repre- 
sent the data contained in the field. Punctuation appears 
in its ASCII format (one character per byte) . Words are 
represented by two bytes, the first contains the vord’s 
initial letter (or digit) which is used to hash into the D3 
dictionary. the second byte is a number used to identify 
the particular member of the linked list hashed to repre- 
senting the target word. 

5 . Keys 

Keys may be thought of as passwords which are used 
to secure records, FOETH screens, and other keys (called 
sealed keys). These objects (i.e., records, screens, and 
keys) all have access descriptor fields which contain infor- 
mation about what keys are necessary to access the 
particular object. Keys allow the user to construct fairly 
complex access mechanisms. 

C. HARDWARE 

Figure 3.1 is a simple picture of the layout of the 
PDBMS's hardware. The system makes extensive use of CMOS 
technology so that it can be battery driven. There are six 
major components in the system. 

1 • Erasable Prog ramma b le a ead -Only Memory 

Erasable programmable read-only memory (EPROM) occu- 
pies the system’s low memory and contains the PDBMS's 
operating system. There are 16K bytes of EPROM in the 

system. As its name implies, its contents cannot be altered 
by the user. 
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Figure 3. 1 



PDBflS Hardware Configuration. 
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2 . 



Ra ndom Acc ess Memory 

Random access memory (RAM) is used by the user as 
his workspace. System parameters and data structures which 
change according to the runtime environment are also main- 
tained in RAM. There are 1 6K bytes of RAM. 

3. Elect rica lly Erasable Programmable Rea d-Only Memory 

Electrically erasable programmable read-only memory 
(EEPROM or E 2 PROM) serves as the system's secondary storage. 
The unique characteristic of E 2 PROM is that it can be erased 
(i. e. , written into) under software control, as RAM can, but 
it is non-volatile (i.e. , its contents are not lost when the 
power is turned off). Part of the E 2 PR0M is not accessable 
to the user because it is used by the system for E 2 ?R0M 
memory management, and database management and storage. 
What is not used by the system is available to the user as 
FORTH screens. 

4. Liqui d Crystal Display and Keyboard 

The liquid crystal display (LCD) serves as the 
system's console. It contains two rows of 20 characters. 
It is attached directly to the system's bus and any data 
written into memory beginning at address C000H appears on 
the LCD. The keyboard provides the means by which the user 
can directly input data into the system. It is connected to 
the system's bus via a parallel I/O port. 

5 . C ent ral Processing Unit 

The PDBMS uses an MSC800 microprocessor operating at 
a clock rate of 1 Mz. This is a CMOS microprocessor which 
is downwardly compatible with the Z80. It was chosen as the 
system's CPU because of its low power consumption and the 
availability of software. The slow speed is not an issue 
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with this system because of the naturally slow 
human-computer communications. 

6. RS232 Serial I/O Port 

This port allows the user to interface 
with other systems. 



nature of 



his system 
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IV. DET AILED PDBMS SYSTEM DESCRIPTION 
A. C0NVENTI08S AND NOTATION 

The nature of words in FORTH does not lend them to be 
referred to by enclosing them in quotes, so instead they 
will appear in upper-case boldface. However, because 
boldface punctuation is often hard to distinguish from 
standard text punctuation, the following eight FORTH words 
will be enclosed in braces: 

. • *•>»*• 

Additionally FORTH words composed entirely of strings of 
these characters will be enclosed in braces (for example, 
{•"}). 

Finally, to avoid ambiguity, the following conventions 
will be used when using the three words "key,” "word," and 
"dictionary." When there is a possibility of confusing the 
FORTH meaning of "word" (described below) and the accepted 
computer term "word" (i. e. , two bytes or 16 bits on the 8080 
and Z80 microcomputers), the former "word" will be called a 
"word" or a "FORTH word," whereas the latter "word" will not 
be used, instead "two bytes" will be used. Adding further 
possibilities for confusion is the third meaning of "word." 
This third meaning is the usual English connotation of 
"word" and these "words" are data in the PDBMS. The ubiqui- 
tous FORTH response, "OK," and words entered by the user as 
responses to the system prompts and as data to be included 
into the database are "words" in this third class. Data 
words of this type will ba called "uwords." Because uwords 
entered into the database may be altered before they are 
entered into the database dictionary, the words which reside 
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TABLE I 

BNP Definition of Oword and wordd 



uvord ::= 
punctuation 
space ::= 
wordd :: = 
char : := 



< wor dd> <punct nation > | <punctuation> 

, I . I /I * 1 = |- I <space> jo | ( | ) | : | ... etc. 

2 OH 

< wordd> <char> | <char> 

1 | 2 | 3 1 4 i 5 1 6 | 7 | 3 1 9 | 0|A|3| ... |X|YJZ 



in the database dictionary will be referred to as ,, vordds. ,, 
Table I shows the BNF definitions of both uword and wordd. 

In order to distinguish between a "key” on the keyboard 
and a "Key” which is used as a password to SEAL and UNSEAL 
data objects, the latter "Key" will always begin with a 
capital "K." Finally, because many of the system data 
structures are not only maintained as FORTH dictionaries 
(also referred to as vocabularies) , but wordds are stored in 
a data structure which is not a FORTH dictionary but which 
may also be rightfully called a dictionary, the following 
convention will be followed. When the possibility of ambi- 
guity may exist, the dictionary being referred to will be 
prefaced by its name (e.g., root dictionary, DB dictionary, 
etc. ) . 

B. PHYSICAL HEMORI AND I/O PORTS 

1 . Hard ware and I/O Po rts 

Physical memory is that memory in which FORTH 
programs execute. This memory lies entirely within the 
user’s address space. The PDBHS’s physical memory consists 



33 



of a little more than 32K bytes (see Figure 4.1). The lower 
memory (0000H to 3FFFH) is EPSOM, and the high memory (4000H 
to 7FFFH) is RAM. Additionally there are 256 bytes of 
memory located at addresses CDOOH through COFFH; the first 
40 bytes of these 256 bytes represent the 2 lines of 20 
characters on the liquid crystal display (LCD) . The 
contents of these memory locations are interpreted as ASCII 
encoded data and are mirrored on the LCD. Thus the LCD is 

directly addressable via the system's bus. Finally, memory 

locations FF00H to FFFFH comprise the virtual E 2 PR0M window. 
When a segment is accessed from E 2 PR0M by writing its 
segment number to the segment register and "powering up" the 
E 2 PR0 M, it appears at these addresses and may be read from 
and written to. When E 2 PR0M power is off these addresses 
are invalid. 

There are two ports which are directly associated 
with the user's address space and accessible to him. One 
port is a read-only port used to receive data from the 
keyboard (it is envisioned that the keyboard will eventually 
be tied directly to the system's bus). This port is located 
at F3H. The other port is a DART port configured for an 
RS232 serial interface and is located at FAH. 

Finally three locations are set aside as jump 
vectors. These are predetermined by the NSC800 hardware in 
interrupt mode 1 which mimics the Z80. The cold boot vector 
is located at 00H. The non-maskable interrupt (NMI) jump 
vector is found at 66H. This interrupt is generated by two 
conditions: whenever the system is "turned off" by the user 

and whenever the system is reset (via the reset button). 
Because of the slow nature of the E 2 ?R0M, it may be possible 
for the user to turn the power off or reset the system 
before a write-cycle involving a large block of data has 
been completed. The virtual memory manager is the ultimate 
recipient of Mis. Upon receiving one, it waits for the 
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EEPPOX FORTH Dictionary 



3FFFM 



OP 

OP ♦ 44H 



700F 



708F 
7 OFF 

7FFF 



COOO 

COFF 

FFOO 

FFFF 



System vartaoles 

System Loaded Screen Definitions 
User Dictionary 

I 

Pad 

i 

t 

Parameter Stack 
Incut Message Suffer 

t 

Return Stack 
User vsrfaoies 

Hock/Osta Suffers 



Invalid Address Soace 



LCD Window 



EEPR OH Window 



Figure 4.1 PD88S Physical Henory Hap. 



35 



9 



write-cycle to be completed and then sets bits 1 , 0, and 4 
of the control port accordingly. After doing that, a jump 
to warm boot is executed. Setting bit 4 to one when the 
power switch is in the on position has no effect, so the 
same interrupt handling routine correctly handles both 
interrupt sources. Ten seconds after an NMI generated by the 
power-off condition, the hardware automatically shuts itself 
off, if it is still on at that time. The third location is 
38H which contains the maskable interrupt (MI) vector. Both 
the keyboard and E 2 PR0M generate interrupts which vector 
here; the device requiring service is determined by reading 
the status register {described below). 



Data Structures 



Figure 4.1 shows the allocation of physical memory 
to data structures in the P DBMS . It varies from the config- 
uration in Figure A. 1 only in that it has data buffers and 
pointer buffers. These buffers share memory with the buffer 
blocks. Block and data buffers are not used concurrently so 
they do not occupy the buffer area at the same time 3 . The 
data buffers are used for encoding and decoding individual 
database records. Records are read into the buffers as they 
appear in E 2 PR0M (less key ID numbers and administrative 
pointers) and then are decoded into their ASCII representa- 
tion which is placed into the current record buffer and the 
LCD window. Probably only a portion of the record fits into 
the 40 character LCD. The first two bytes of each data 
buffer contain the resident record's virtual pointer {FFFFH 
indicates an empty buffer). 



3 Even if the PDBMS is designed so that it LOADS defini- 
tions from screens during execution of database operations, 
there is no problem. This is because the block buffers are 
not used during a LOAD; the E 2 PR0M is sirndy read directly 
without using a buffer. 
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The pointer buffers serve several purposes. During 
retrieval operations buffer number one holds the pointers to 
records to which the user is authorized access and which 
have satisfied all query conditions processed so far. The 
second buffer holds pointers to records to which the user is 
authorized access and which satisfy the current query condi- 
tion being processed. After the completion of the 
processing of each query condition the intersection or union 
of the two buffers (depending upon the query) of the two 
buffers is placed into buffer one. 



C. VIRTUAL MEHOBY AND CONTBOL POSTS 
1 . Hardwar e 

In the PDBMS, E 2 PR0M is used as secondary storage. 
A total of 8K bytes of E 2 PR0S is included and it is 
segmented into 32 segments, each 256 bytes in size. 
Segments (analogous to FORTH blocks) are further divided 
into physical records 16 bytes in size. Figure 4.2 shows 
the bus interface of the Intel 2815 E 2 ?R0M chips. As in 
standard FORTH, the user and user programs deal with phys- 
ical addresses only. The user can only refer to virtual 
memory by using screen numbers. However, some PDBMS words 
use two byte virtual addresses to access physical records in 
virtual memory. Only assembly language coded words 

('•low-level" words) can directly fetch and store bytes in 
E 2 PR0M via the window. 

PDBHS virtual addresses consist of two bytes. One 
byte contains a segment number and the other a physical 
record number within the segment. Because only four bits 
are needed to designate a physical record, if it were tech- 
nically feasible the system could accommodate 512K bytes of 
E2PR0M. 
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Data 9 us 




Figure 4.2 2816 E 2 PR0H Configuration. 
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Only 15 of the 16 bits are used for virtual 
addresses. The high bit (bit 7 of the Most Significant 
Byte — MSB) is used to differentiate virtual from physical 

addresses in E 2 PROM and RAM. Virtual addresses which move 
from E 2 PROM to RAM and vice versa must pass through low 
level FORTH words which ensure RAM and E 2 PR0M virtual 
addresses never get mixed in with each other. E 2 PR0M 
virtual addresses have their high bit set to zero while RAM 
virtual addresses have their high bit set to one. Thus 
virtual addresses appear to be out-of-range references 
within the domain in which they occur. For example, if an 
address referenced inside an E 2 PR0M segment is less than 
800 OH , then it is a virtual address to another segment. 
Intra-segment addresses are always greater than or equal to 
FF00H (all of which have a high bit of one) . This means 
that, as in standard FORTH, "programs'* cannot be executed 
directly from secondary storage but must be LOADed first. 
This allows all code field addresses (CFA) to be interpreted 
as physical addresses, whether they occur in RAM, EPROM, or 
E 2 PR0M, so there is no problem associated with storing 

constants and variables in E 2 PR0M. Care must be exercised 
to ensure that LCD window addresses are never used in the 
same RAM context as RAM virtual addresses since they would 
be indistinguishable from each other. 

The E 2 PROM can be read in 450 usee, however it 
requires 20 msec 4 to write one byte (all of the bytes on 
each chip may be erased in one 10 msec operation) . 
Additionally the 2816 must be strobed with a 21 volt pulse 
during the write process. This means that E 2 ?R0M cannot be 



♦Intel literature states that their S 2 PR0M requires 10 
msec per write, which is true. However, in order to ensure 
that the data is properly recorded, the addressed byte 
should contain FFH berore it is written into if a write 
requires a zeroed bit to be changed to one. Thus writing 
involves two write operations: one to set the target byre to 
FFH, and a second to write the desired value. 
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treated the same as RAM. Other non-volatile memories were 
considered for this design, such as NOVRAM and Instant ROM. 
Both of these alternatives can be treated almost as if they 
were RAM, however they were judged unsuitable. NOVRAM was 
not found to be a feasible choice because of its small size- 
The largest NOVRAM chip contains only 256 bytes, thus 8K of 
NOVRAM cannot be battery powered because of the large number 
of chips that would be required. Instant ROM was also found 
to be undesirable because it contains its own battery power. 
The on-chip battery is guaranteed for three years, and this 
is hardly suitable for a permanent database. Currently 
available hand-held computers use concepts similar to 
Instant ROM, they use CMOS memories which are constantly 
refreshed, even when they are turned "off." 

The E 2 PR0M and the PDBMS is controlled through three 
control ports. One port, the segment register, is used to 
select the desired segment. This port is located at F8H and 
is write-only. The second port is the status register. It 
is located at F9H and it is read-only; it reflects the 
system's current status. Figure 4.3 shows the status port's 
configuration. Complementing the status register is the 
control register which is a write-only port located at F9H. 
The control register is used to effect system changes. This 
port is described in Figure 4.4. These ports, as well as 
all other ports, are "smart" ports in that they only accept 
instructions from code being executed from EPROM. It does 
this by checking the program counter which the NCS300 places 
on the address bus prior to fetching an opcode fetch. If 
the A 15 and/or A14 lines of the address bus are high the 
next instruction is ignored. E 2 PROM power and write-power 
are turned on and off by setting bits 0 and 1 accordingly. 
Whenever either of these bits is set to one, bit 7 of the 
status register is set to zero. After the chips have been 
powered-up, bit 7 of the status register is set to one, so 
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Boot-up Values 



Bits 



7 



6 



5 



4 



3 



2 



1 



0 



Flag Meanings 

It eCPRCM r«»ay 
Ox EEPftON not reedy 

il EEPQON »rft*-po«*r I* on 
Ox CEPROM write-power le off 



lx EEPPOM Interrupt pending 
0: No EEPflOM Interrupt pending 



0 



Not uwed 



n/a 



Not u*ed 



n/a 



lx Keytwerd Interrupt pending 
Ox No keytwtrd Interrupt pending 



lx UAAT receiver reedy 
0: UART receiver not retay 



n/a 



lx UAftT tren**ltter reedy 
Os UAPT trine* It ter not reedy 



n/a 



Figure 4.3 Status Port Flags {IN 9FH) . 
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is bit 6 or 5 (depending upon whether bit 0 or 1 of the 
control register had been set). Additionally, whenever bit 
7 is set to one (except during a cold boot of the system) , 
an HI is generated. When bit 7 of the control register is 
set to one, bit 7 of the status register goes to zero. When 
the E 2 PROM write-cycle has been completed, bit 7 goes high 
and an HI is generated. 

Changes in bits 0 and 1 of the status register do 

not generate interrupts, but when bit 2 goes high (indi- 

cating keyboard input) an MI is generated. Reading the 
status register resets bit 2 to zero. 

Notice from Figure 4.2 that the four 2816 chips are 

interleaved so that all addresses equal to zero, mod four, 

are on the first chip (i. e. , those addresses whose last 
hexadecimal digits are 0, 4, 8, or C) . Those equal to one, 
mod four, are on the second chip, etc. This arrangement 
facilitates fast writing of blocks of data to E 2 PR0M because 
four contiguous bytes may be written simultaneously. Thus 
in the best case (when four contiguous bytes are written) 
the average write-time per byte is approximately 5 msec and 
an entire segment can be written in 1.25 seconds. Actually 
more time is required, but the additional time is minor when 
compared to the gross nature of the E 2 PR0M write-time. The 
additional time involves reading and comparing the contents 
of the E 2 PR0M to the appropriate buffer’s contents (data or 
block buffer) . The entire write-cycle algorithm is shown in 
Table II. 

2. O rga n iz ation and Data Structures 

The 8K bytes of E 2 PR0M are divided into two types of 
segments: system segments and block (or screen) segments. 

System segments are owned by the system and cannot be 
directly accessed by the user or his programs. Block 
segments are those which contain screens, in the usual FORTH 
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Bits 



BJt Set Meanings 



7 



6 



5 



4 



3 



2 



1 



Q 



1: Stort EEPBCM orlto-cyclo 
•t Ho rffoct 

Not ucod 



Not used 

It Turn systes off (EEPRCM oust be off first) 
Os No effect 



Not used 



Not (Med 

it Turn EEPRtX srf te- volte ge on 
•t Turn EEPftCH srtte-cycle voltage off 

lx Turn EEPRON poser supply on 
9: Tern EEPROM poser supply off 



Figure 4.4 Control Port Flags (OOT 9FH) . 
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TABLE II 

Virtual Memory Write-cycle Algorithm 



J = START_OF_SEGMENT; 

REPEAT UNTIL N0_ MORE_B YTES ; 

DO I = J TO J+3 ; 

READ S 2 PROM_ BYTE ( I ) ; 

IF BUFFER_BYTE (I) * S 2 PROM_B YTS (I) THEN DO; 

IF BUFFER_BYTE (I) & E 2 PR0M_BYTE (I) * 0 THEN 
E 2 PR0M_BYTE ( I) = FFH ; 

E 2 PROM_BYTE (I) = BUFFER_3 YTE (I) ; 

END DO; 

END DO; 

CONTROL_?ORT_BI TS (7) = 1; 

LOW POWER HALT; /* WAIT FOR INTERRUPT =V 
DO I = J TO J+3 ; 

READ E 2 PR0M_ BYT E (I ) ; 

IF BUFFER_3YTE(I) * E 2 PROM_3 YTS (I) THEN 
SIGNAL (E 2 PROM_W RITE_ERROR) ; 

END DO; 

J = J + 4; 

END REPEAT; 



sense, and are available to the user. Blocks are allocated 
sequentially in a round- rob in fashion by the memory manager. 
This means that the next segment to be allocated is the next 
higher unallocated segment after the last allocated segment. 
When the 32nd segment is reached, allocation begins again 
from the first segment not initially assigned to the system 
(i. e. , when the software was placed into the system). This 
scheme is used in an attempt to more uniformly distribute 
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V 



the E 2 PR0tl use. If a '’lowest available segment algorithm" 
were used, there would be a higher probability that portion 
of E 2 PRO M assigned to the low numbered segments might "burn 
out" (E 2 PRO M is limited to 10, 000 write operations to each 
individual byte) . 

a. System Segments 

System segments are those which are used by the 
PDB MS for virtual memory management data structures and the 
database. The user cannot directly access these segments 
because any segment allocated to the system is not placed in 
the block number dictionary. System routines address these 
segments directly (i.e. , they "know" the physical segment 
numbers whereas the user knows only virtual block or screen 
numbers) . At least four segments are dedicated to the 
system; the system and the user compete for the remaining 
segments (less system message screens) which are allocated 
on a first-come, first-serve basis. Additional system 
segments (beyond the dedicated four) are used to accommodate 
the expanding database. Because the database resides in 
system segments, the user cannot see their physical struc- 
ture; he is limited to viewing it through the PDBMS. The 
first four segments are structured as described below. 

( 1) • P ar ame ter Tab le. This segment contains a 
collection of system parameters and tables. For example, 
most of the cold boot parameters are loaded from here. Also 
located here is the vocabulary table. 

(2) . Key Sub- D ictionar y. Security in the PDBMS 
is provided in part by Keys. These Keys are used to seal 
records, blocks, and other Keys. These Keys are maintained 
in a linked list dictionary as a separate VOCABULARY. The 
Key vocabulary definition is located in EPROM. The code 
pointer of each Key points to the run-time code for CONSTANT 
which is located at dccon. Thus when the Key is executed. 
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it returns the contents of its two byte parameter field 
address (PFA) . The value held in the PFA may have two mean- 
ings. If the value returned is less than 128, then it is 
the Key's identification number (ID). If it is greater than 
128, then the value returned is a virtual pointer to a 
sealed record containing the Key's ID number. The Key ID 
value, FFH is reserved for the null Key, while the value OOH 
is reserved for the system's Key. Also the value FEH is 
used as a substitute ID for the ID value of deleted Keys' 
IDs in access descriptors. The use of Keys is discussed in 
greater detail in Chapter 71. The Key vocabulary, besides 
containing Keys, contains words; these words are stored in 
EP80H. 

(3) . Bl ock Nu mber Dictionary. The segment 
containing this is divided into three parts. Four bytes are 
set aside as the segment allocation table, four bytes are 
used as the segment allocation sequencer table, and the rest 
of the segment is used as a vocabulary for virtual block 
numbers. Each bit in the segment allocation table repre- 
sents a segment. If a bit is set to one, the corresponding 
segment has been allocated. The sequencer table has only 
one bit set, the one corresponding to the last segment allo- 
cated. 

The virtual block numbers are maintained 
as a FORTH vocabulary, as are the Keys. Also like the Key 
vocabulary, the definition of the block number vocabulary is 
located in EPROM. However, unlike the Keys, virtual block 
numbers are fixed length name, one byte constants. This 
allows virtual numbers to be assigned to all of the origi- 
nally unallocated segments. This limits block numbers to 
four characters in length. This dictionary is static and 
always contains 28 entries. Entries are removed from the 
dictionary by blanking out their virtual number (i.e., the 
entry's name field) and setting the smudge bit so they will 
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not be found. When a virtual block number is entered by the 
user, the entire dictionary is searched. For example the 
following keyboard entries would trigger searches of the 
dictionary for "I” and 11 25 '* respectively. 

1 LIST 
25 LOAD 



If "I" had not been found in the dictionary a block buffer 
(located in physical memory) would have been allocated to 
virtual block "1." The virtual number "I" would not be 
entered into the block number dictionary until it was 
written to E 2 PROM. If "2 5” had not been found the usual 
FORTH error condition would have been raised. 

(4) . The Data base Segm ent . This block is 
broken into two parts. The first contains a jump table into 
the DB dictionary. There is one jump vector for each prin- 
table ASCII character allowed by the system (a maximum of 
64) . A character's jump vector is hashed to using the 
following equation on the character's hexidecimal value 
(called "char") . 

Location of jump vector - 

( (char - 32H) 3 2) + FFOOH 

If the vector is equal to zero, then the character is punc- 
tuation (as described in Table I) . Punctuation is not 

stored in the DB dictionary. If the vector is equal to 
FFFFH (uninitialized S 2 ?R0H), then there are currently no 
wordds in the dictionary starting with that letter. 
Otherwise the vector is the virtual address of the first 
physical record in an alphabetical linked list of wordds 
beginning with that letter. The next four bytes of this 
segment contain a bit map of the segments. Lika the segment 
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allocation table, a bit is set to one if the corresponding 
segment belongs to the database. 

The second half of this database segment 
is used for the beginning of the file and field name vocabu- 
lary. Field entries are simply FORTH constants which return 
their field ID number (0 to 255) . File entries are modified 
FORTH vocabulary definitions (they contain five extra bytes 
used to store pointers to the first and last records in the 
file, and a field count) . The field names are entries into 
the "file vocabulary" to which they belong. This allows 
FORGET to be used to delete files. Of course FORGET is not 
sufficient by itself; the virtual memory allocated to the 
forgotten entries must be turned bach to the system. 
Because of the nature of record entries in the PD BUS , fields 
cannot be individually forgotten. As with the Key vocabu- 
lary, the file vocabulary definition, as well as some other 
words, reside in EPROM. 

When information is added to the database, 
it expands in three ways. First the file and field vocabu- 
lary grows to accommodate new file and field definitions. 
This dictionary may spill into additional segments. 
Allowing this dictionary to exist in more than one segment 
creates some problems which must be specifically addressed 
by the interpreter/compiler. Off-segment references can 
only address 16-bit physical records, so entries of this 
type cannot be positioned in a "forma t- free" manner. Thus 
entries in this vocabulary are all placed in memory taking 
the physical record into consideration (i.e. , beginning on a 
physical record boundary). A benefit of this is that the 
entries may be mixed into the same segments with the D3 
entries, file logical records, and sealed Keys. 

The database itself may be considered a 
totally inverted file system. Records contain only PDBMS 
information and pointers to dictionary entries of wordds 
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which appear in the record. Figure 4.5 shows a typical 
entry in the PDBHS. The system knows how many fields are in 
the currently open file, so it uses the last field's 
end-of-field (EOF) as the end of record marker (EOR) . The 
EOF is the same character as the null Key, making FFH (blank 
E 2 P 30 M) a general system end-of-data marker. When a logical 
record is broken over a physical record boundary, the last 
two bytes of the physical record contain a pointer to the 
next physical record. 

Fields are strings of ASCII characters 

followed by an entry ID number. The ASCII letters are the 
initial letter of the wordds (i. e. , transformed uwords) 
originally entered into the record by the user. The letters 
are used to hash to the jump vector table on the first 
segment of the database. DB dictionary entries are main- 
tained in an alphabetical linked list. The correct wordd 
corresponding to the uwori entered into the record is found 
by matching the ID number following the letter used as input 

to the hash function to the ID number of a wordd on the 

linked list hashed to. Punctuation is not followed by an ID 
number and the record decoding routines "know" not to look 
for an ID number in the record because punctuation jump 
vectors are equal to zero. 

Figure 4 .6 shows a typical dictionary 

entry. This structure is an expanded and modified version 
of the one used in Craig language translators [5], The 
entries are designed to take advantage of the alphabetical 
nature of English language dictionaries. The first byte 
contains a zero and is ignored when traversing the DB 
dictionary during a wordd look-up. It is placed there to 
prevent an accidental retrieval by non-dictionary routines 
which always treat the first byte as a Key. The second 
byte, the copy byte, contains the number of leading charac- 
ters in the current wordd which match the leading characters 
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Pigure 4.5 Database Physical Becord structure. 
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in the previous wordd on the linked list. The link bytes 
contain a pointer to the next wordd in the linked list. The 
add byte contains a number, which when added to the 
"copy byte ♦ 1" character of the previous wordd yields the 
correct "copy byte + 1" character of the current wordd. The 
bytes following the add byte contain the ASCII characters of 
the current wordd after the "copy byte + 1" character. The 
last character’s high bit is set to one as an end of string 
delimiter. If there are no characters following the 
"copy byte + 1" character then the byte following the add 
byte contains FFH (which translates to an ASCII delete). 
The wordd ID byte contains the wordd' s ID number. This is 

used when decoding records. Figure 4.6 shows how the DB 

entries for "FORGET" and "FORTH" would appear if they were 
consecutive entries and "FORGET" was the first "F wordd." 
Following the last unique character is a linked list of 
field ID numbers with pointers to records containing the 
field associated with its corresponding field ID. These 
field numbers and pointers are used in retrieval operations. 
Records are retrieved by specifying field names and uwords. 
Obviously punctuation cannot be used for retrieval since 
only wordds are stored in the DB dictionary. 

Figure 4.7 shows how the dictionary is 
traversed to find the desired wordd. Owords are reassembled 
in the PAD by making the changes indicated by the copy byte, 
add byte, and unique characters as the list is traversed. 
That is, when the DB dictionary linked list is entered, the 
first wordd in the list is copied out into the PAD. If this 
is the not target wordd, then the second entry in the linked 
list is moved to. Using the information in the copy byte, 
the add byte, and the unique characters, the second wordd in 
the list is constructed. In moving from "FORGET" to "FORTH" 
as shown in Figure 4.6, "FORGET" would be written into the 
PAD as the first wordd in the linked list of "F wordds." 
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When the search continued past "F0R32T" because it was not 
the target wordd, the first three letters in the PAD would 
be left because the copy byte of the second entry is 3. 
Then 13 would be added to the fourth letter (G) because that 
is the contents of the add byte. This would change the 
fourth letter from a "G" to a "T." Then the fifth letter, 
and any subsequent ones, would be replaced by the the unique 
characters (in this case "T" would be overwritten with an 
"H"). At this point the PAD contains the wordd "FORTH." 

Once a wordd has been placed into the 
dictionary, its first physical record is never returned to 
the system to be reallocated. If all instances of a wordd 
are removed from the database, the high bit of the copy byte 
is set to one. Subsequent searches of the dictionary will 
not "see" a wordd if its copy byte contains a negative 
number (two's complement). Because the dictionary is a 
linked list, this memory may be reused in the same list by 
reattaching it at a different point in the list. When the 
first record is reused, the new wordd placed in it uses the 
ID number assigned to the first wordd to use the record. 
This is done to make ID assignment easier and to stave off 
the possibility of running out of ID numbers 5 . Physical 
records other than the first may be returned to the system 
when a wordd is deleted. 

In segments acquired by the system to 
accommodate database expansion, only 15 physical records are 
used for the database. The first record (record 0) contains 
administrative information such as a record allocation map 
for the segment. 



5 The ma?imym ID number is 255. The statistics in 

Appendix B indicate that, even m an aggregate of four 
address books, the maximum number of unique wordds is not 
that large. 
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b. Screen Segments 



These segments belong to the user for use as 
FORTH screens. A screen segment is divided into two parts. 
The first physical record contains the screen’s access 
descriptor. The rest of the records contain the part of the 
segment the user sees as a screen. A screen consists of 16 
rows of 15 characters. This is much smaller than the 
standard FORTH screen which is 16 rows of 64 characters. 
The smaller screen is better suited to the 2 row by 20 
character LCD. 

When the system is first initialized (i.e., when 
the software is first placed on the hardware), some of the 
screen segments are used to store system messages, as in 
standard FORTH. Additionally, some screens are used to 
store some of the definitions used in the PDBMS , particu- 
larly those used with the naive user interfaces. This 
allows the user to eliminate or change these definitions and 
system messages as he sees fit. 
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V. THE DEVICE DESCRIPTION 



At the time of this writing, the PDBMS is in the process 
of being prototyped. This first prototype is not intended 
to meet all of the desired characteristics of a PDBMS . For 
example, it cannot be hand-held because it is bread-boarded 
and a standard keyboard is used; additionally it requires 
more than one power supply because not all of the CMOS 
components have been received. What is described in this 
chapter is the outline of the final prototype as it is envi- 
sioned at the present time. For the most part, this is a 
description of the PDBMS as it would appear to the user. 

A. THE HARDWARE 

From the user's point of view, the hardware consists of 
four major components: 1) the enclosure, 2) the display, 3) 

the keyboard, and 4) the electronics inside. These aspects 
involve how the system physically appears to the user, not 
how he perceives it to work. 

1 • The E nclosure 

The enclosure should be as small as possible and yet 
still be useful. The major constraints upon how small the 
PDBMS can be made are the size of the display and the 
keyboard. The minimum practical size available with 
currently available products is approximately 9 inches (23 
cm) by 4 inches (10 cm) by 1 inch (2.5 cm). This is the 
average size of most of the hand-held computers today, such 
as those made by Panasonic, Radio Shack, and 1X0 [6 and 7]. 
These systems tend to weigh around 14 ounces (400 got) . 
Their size seems to be the smallest practical one in order 
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to keep the keys far enough apart to minimize the chances of 
hitting the wrong key or hitting two keys at once 6 . It is 
doubtful that the display will be shrunk; if anything, 
future displays will be larger and allow smaller fonts, thus 
allowing more information to be shown. Ultimately, it could 
be possible for the display to dominate the front of the 
PDBMS if voice input were incorporated. This would most 
certainly require a large display because function keys 
would probably not be used (or even desired) and the system 
would be expected to echo all vocal input so that the user 
could verify that he had been correctly understood. 

The back of the enclosure opens to allow batteries 
to be changed and E 2 PR0M to be added in or taken out. This 
last feature would not only allow the user to expand his 
memory (or treat it like a floppy disk, i.e., interchange- 
able secondary storage), but also allow the transportation 
of software and data from one PDBMS to another by a means 
other than through the RS232 port. The hardware and soft- 
ware of the first prototype do not include an ability to add 
more E 2 PROH, but the required modifications are minor. 

It should be mentioned that the current implementa- 
tion of Keys does not gracefully support the transportation 
of sealed objects from one system to another by physical 
transportation. There is no way to guarantee that security 
would be uniformly enforced, independent of the system in 
which the objects are found, because key assignments are 
local in context. 



6 The size of the kevs is peally unimportant so long -is 
the user feels comfortable using them. This normally is 
taken to mean that the keys should not be physically uncom- 
fortable to use and they should provide some sort of tactile 
and audible response upon being struck. 



57 



2 . The Display 

The current display is an LCD which contains two 
rows of 20 characters each. This is larger than the 
displays in most of the currently available hand-held 
computers. These normally have one row of 16 to 20 charac- 
ters. It was felt that two lines were the minimum 
acceptable number of lines for the PDBHS. Two lines allow 
user commands and responses to appear on one line and the 
system responses and prompts to appear on the other. This 
allows the user to compare his commands and responses with 
the system’s. Ideally the PDBHS should have a larger 
display. The largest LCD displays available at this time 
have four lines with 40 characters par line, however these 
are too expensive to be compatible with cost criteria of the 
PDB MS 7 . 

3 . The K eyboar d 

Host of the keys should be 3/16 inch (0.5 cm) square 
and protrude from the keyboard background by 1/8 inch (0.3 
cm). The keys are separated by 1/4 inch (0.6 cm). These 
dimensions are used on most of the Hewlett-Packard calcula- 
tors for the arithmetic keys (i.e. , + - + x) . Using them 

as an example, the author found that keys were easily 
differentiated from one another, and two or more keys were 
almost never pushed simultaneously. The keys should be 
arranged by function with the background colored differently 
for the letters, numbers, and special function keys, similar 
to what was done on the Quasar and Panasonic computers [6]. 
The on/off switch should be away from the other keys and be 
a sliding switch, not a push switch. This should be done to 



7 LCD is the only flat d+splay technology presently 
available which is power efficient enough to be used in a 
good battery powered system. LSD and plasma displays are 
much less power efficient. 
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help prevent the accidental switching on or off of the 
pow er . 

The letter keys should be arranged in the standard 
"QWERTY" format, not only because of the entrenched place in 
the English speaking world [ 1 ], but also because it has been 
found to be more effective than previously thought relative 
to some keyboards designed using human engineering princi- 
ples, especially with novice users [9]. At the present only 
upper-case letters are planned no be provided to the user 
for text entry. Below is a list of the keys and their 
functions. 

a. Letter and Digit Keys 

These keys act in the usual and expected 
fashion; they are used to enter the ASCII representation of 
the desired character. Input from these keys is handled as 
it normally would be in any FORTH system. The letter keys 
may also be used as "function keys." When shifted, using 
the shift key, the ASCII code for the key's lower-case 
equivalent is generated. These "illegal" characters are 
treated similarly to LaFORIH words; that is, they are inter- 
preted immediately upon input [9]. Initially the function 
accomplished by these words is to place into the input 
message buffer and the LCD window the ASCII string represen- 
tation of other words; they do not appear in the input 
message buffer or on the LCD 8 . For example, in the database 
management application a shift-G causes the word GET to be 
placed in the message buffer and the LCD window so when the 
return key is eventually pushed, WORD will find GET in the 
buffer, not shift-G. Notice that the keys may perform 
different functions depending upon the current vocabulary. 



8 When they must be displayed, as i$i their colon defini- 
tions, they are displayed m "reverse video." 
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b. Mathematical Keys 

These keys are similar to the shifted lettered 
keys, however they act as input immediate words without 
shifting them. That is, they always cause a search of the 
current vocabulary. This was done so that the user can 
choose to use either infix or postfix notation (infix nota- 
tion is the default definition of these keys in the "naive' 1 
calculator vocabulary). These keys include the following 
five keys: 

+ - x -i- % 

c. Special Function Keys 

These keys are the usual terminal editing keys, 
and with the exception of the "NEXT" keys, they are not 
programmable. The keys are described below. 

(1) . Enter . This key causes a carriage return 

and line-feed to be placed into the input which is reflected 
upon the LCD. This causes the interpreter to begin parsing 
the input. 

(2) • D el . This causes a control-H to be input 
and acts as a character deletion key. It backs up the 
cursor cne position and displays a space on the LCD. 

(3) . This moves the cursor to the right one 

character position without effecting the contents of the LCD 
window cr the message buffer. 

(4) . + . This moves the cursor to the left one 

character position without effecting the contents of the LCD 
window cr the message buffer. 

(5) . Shift . This is a non-locking shift key 
used with other keys to elicit their alternate definitions. 

(6) . X>. This deletes all input from, and 

including, the current cursor position to the end of the 
line. 
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(7) . NEXTt, and NEXT + . These keys are used to 

scroll the display to the next line above or below, respec- 
tively. In the database application, the shifted NEXT keys 
are used to scroll to the next field above and below the 
current field. This allows fields to include carriage 
returns and line-feeds so that a field need not be 
constrained to one logical line on the display. 

B. THE SOFTWARE 

When the user initially receives the system, he is 
presented only with two functions: a calculator and a data- 

base manager. He does not have direct access to ROOT. This 
was done to help prevent the user from inadvertently 
destroying the system before he understands it. For 
example, it prevents him from redefining or forgetting a 
word accidentally. The user can expand the scope of the 
system gradually as he learns more about it until he can, if 
he chooses, run it strictly in FORTH (or even redesign the 
system to a great extent) . This flexibility is gained by 
using FORTH execution vectors. In the case of interfacing 
with different levels of users, there is a different version 
of FIND for each level of user sophistication. So as the 
user becomes more adept with the system, the vector associ- 
ated with FIND is simply made to point to a new, more 
powerful version of FIND* s run-time code. The version 
initially available to the user only searches the limited 
calculator and database management vocabularies; the ROOT 
vocabulary is not searched. The version available to the 
most sophisticated user includes a modified version of the 
standard FORTH FIND. All FINDS have been modified to be a 
little more user friendly. Instead of reporting the usual, 
"IS UNDEFINED," when a word is not found, the PDBMS reports 
the current vocabulary's name as well. So for example if 
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